home *** CD-ROM | disk | FTP | other *** search
/ SPACE 1 / SPACE - Library 1 - Volume 1.iso / program / 113 / gfatip11 / gfatip11.doc < prev   
Text File  |  1987-11-01  |  9KB  |  191 lines
  1.  
  2.  
  3.                                                 November 1, 1987
  4.  
  5.  
  6.                            GFATIP11.DOC
  7.  
  8.                         by John B. Holder
  9.                      Senior Software Engineer
  10.                      Marathon Computer Press
  11.            Asst. Sysop on GEnie's MichTron Roundtable
  12.  
  13.  
  14.      This is the 11th in a planned series of GFA Tip files.  The 
  15. topic of this issue is using Desk.Acc's from within a running GFA 
  16. Basic program without punching a hole in the screen when the 
  17. accessory exits.  In this archive you will find the following 
  18. files:
  19.  
  20.                             Accfix.Bas
  21.                             Accfix.Prg
  22.                            GFATIP11.Doc
  23.  
  24.      The enclosed files will be pretty much self explanatory, so I 
  25. will keep this Doc file to a short explanation and take a few 
  26. lines to make a warning or two.
  27.  
  28.                            The Problem?
  29.  
  30.      The problem with the current version of GFA Basic is that 
  31. when a Desk Accessory is selected and then exited, a nice gaping 
  32. hole is left in the middle of the screen where it once lived.  
  33. This is due to a number of reasons.  The main one being that the 
  34. Developer chose to present a white background screen most likely 
  35. cleared with a VT52 Clear Screen command.  Aside from the obvious, 
  36. it has become painfully obvious to GFA Basic Programmers and 
  37. Developers.  The worst part is that it is almost impossible to 
  38. detect when an accessory is either opened, or closed with GFA 
  39. Basic unless you resort to numerous GEM calls that are very 
  40. confusing and unforgiving.  If you happen to be one of those that 
  41. prefer the hard way, more power to you.  A good reference would be 
  42. The GFA Basic Book (By MichTron) if you choose the GEM route.  For 
  43. the rest of the world, myself included;  I have created this tip 
  44. file to solve the problem.
  45.  
  46.                           The Solution? 
  47.  
  48.      Our chosen solution is foolproof only if the program user is 
  49. willing to cooperate a bit, and if you keep a few things in mind 
  50. when developing your programs.  I'll leave the nitty gritty 
  51. details to the commented GFA Basic source code, and only mention 
  52. the cooperation details and the warnings.
  53.  
  54. Cooperation:
  55.      This fix requires the User to tell the program when they 
  56. want to use an accessory, & then tell the program when he or she's 
  57. done with it.  To enforce this option, we disable the desk 
  58. accessories right off the bat, (see the source for details).  Next 
  59. we offer a Menu Option "Accessory".  Under this option there are 
  60. two choices, "Use an Accessory" & "Return".  When "Use an 
  61. Accessory" is selected a series of reactions take place.  They 
  62. are:
  63.  
  64.                               Part 1
  65.  
  66.      1. See first if the option is already selected.  If it is, 
  67. let's just ignore the request.
  68.      2. Check to see if we have 32000 bytes of spare memory for 
  69. the screen buffer.
  70.      3. If so set the ACCSHOW variable (means we're gonna' do it).
  71.      4. Grab the currently displayed screen.
  72.      5. Put up a GEM Desktop compatible chalkboard, (background 
  73. color and fill pattern for the current resolution) for the 
  74. Accessory to work on.
  75.      6. Enable all of the present Accessories that are being 
  76. reported to the GEM menu.
  77.      7. Disable all of the other options in the GEM Menu until we 
  78. are done with the Accessory. 
  79.  
  80.                               Part 2
  81.  
  82.      If the "Return" option is selected we start a series of 
  83. reactions that go something like this:
  84.      1. Is the ACCSHOW variable set?  If so then this is a valid 
  85. call, if not just ignore it.
  86.      2. Next we put the screen buffer back into place, just as it 
  87. was when we decided to use an Accessory.
  88.      3. Clear the ACCSHOW variable.
  89.      4. Clear the Screen Buffer and return the 32000 bytes to the 
  90. dynamic memory pool so it can be used by the application.
  91.      5. Force the application to do some garbage collection.  Only 
  92. takes a microsecond (give or take a few picoseconds) <grin> & 
  93. helps out with memory management and can speed up the running of 
  94. the application.
  95.      6. Re-enable all of the regular menu options and disable the 
  96. Desk.Acc options.
  97.      7. Get back to your application and allow GEM to handle the 
  98. user interface.
  99.  
  100.  
  101.                           ** Warnings **
  102.  
  103.      The user must be told in documentation that if they select 
  104. the "Use an Accessory" option that they MUST properly close the 
  105. Accessory before choosing the "Return" option.  Failure to do so 
  106. will cause the accessory to be hidden behind the Screen Buffer 
  107. replacement screen when "Return" is chosen.  This is bad for a 
  108. number of reasons.  It can cause the Desk.Acc to interact with 
  109. your program when returning.... Ie.. mouse click on a hidden 
  110. dialog box, or worse.  Not good!  Hey, then again;  How many 
  111. people use an accessory and then don't close it?  Believe me, they 
  112. will try if you don't tell them first that this is a no no.  We 
  113. don't want hate mail from a disgruntled User do we?  So the moral 
  114. of the story is tell them that you want them to be able to use 
  115. accessories, but they need to cooperate and tell you when they're 
  116. done.  Sounds Fair, Right?  In return, there won't be any 
  117. unsightly holes punched in the screen when a Desk.Acc is used.
  118.  
  119.      The second warning is to those that are using applications 
  120. that may have a GEM window on the screen when "Use an Accessory" 
  121. is selected.  If this is the case, you should do a few things in 
  122. order to make the option work properly.  They are:
  123.  
  124.      1. Either close your window first <or>
  125.      2. Fullw(#) and then Clearw(#) before allowing the "Use an 
  126. Accessory" option to draw the chalkboard.
  127.  
  128.                                Why?
  129.  
  130.      By the nature of GEM, all graphics commands are automatically 
  131. directed to the currently active window.  Therefore, if a window is 
  132. open the chalkboard will go into IT and not the entire screen as 
  133. is intended.  So... Big deal?  Well, if your active GEM window is 
  134. not "Fulled"  we won't get the full protection of the temporary 
  135. chalkboard since the Desk.Acc may appear anywhere on the screen or 
  136. perhaps be moved anywhere on the screen.  Take my word for it, 
  137. I've tried and failed any other way.  In a nutshell, if you allow 
  138. the access to the GEM menu bar while a window is displayed, it's 
  139. best to first close the window(s) and then let "Use an Accessory" 
  140. do it's work.  Following the "Return" you can always reconstruct 
  141. the screen.  To detect that you can place a Flag variable at the 
  142. end of the "Return" menu option handler to signal that a Redraw is 
  143. necessary.
  144.  
  145.                          Closing Comments
  146.  
  147.      Although not entirely foolproof, this method of utilizing 
  148. Desk Accessories is the most complete and clean way I've seen so 
  149. far.  It's sure better than some Kludge to detect if a point on 
  150. the screen has been altered and then try to do a redraw!  If used 
  151. properly, it should suffice in the pursuit of allowing Users to 
  152. use their Accessories, while maintaining screen integrity.  
  153. Hopefully a spirit of cooperation will prevail and everyone will 
  154. be happy.
  155.  
  156.                           The Way Ahead?
  157.  
  158.      The developer of GFA Basic has stated that he'll attempt to 
  159. come up with a fix for the current Desk.Acc malady with the next 
  160. version (3.0) due in the late spring of 1988.  There were no 
  161. promises made though, so don't quote that statement and try not to 
  162. be disappointed if it doesn't happen.
  163.  
  164.                      Comments and PD release
  165.  
  166.      This GFATIP file is in the public Domain.  However, the 
  167. documentation file is Copyright (c)1987 by Marathon Computer 
  168. Press, and is provided as a public service.  You may not include 
  169. the text of this file in any publication, or newsletter without 
  170. the approval of Marathon Computer Press.  The source code and idea 
  171. are free for grabs.  You may also post this file on any bulletin 
  172. board as long as it is posted in it's entirety.  No charge (of any 
  173. kind) may be assessed for providing this Tip to the public.  If 
  174. it's not 100% Free, don't do it!  Nuff Said.
  175.  
  176.      I hate to have to do this, but some people have been selling 
  177. my GFATIP series at a profit.  If anyone has a right to do that, 
  178. it's Marathon Computer Press & nobody else.  I hope you 
  179. understand.  If you have comments concerning this file, or any 
  180. other GFATIP file you may leave electronic mail for me on:
  181.  
  182.                   GEnie =>   GRIFJOHN
  183.                   CIS =>     75766,505
  184.  
  185.                            Or Write to:
  186.  
  187.                      Marathon Computer Press
  188.                           P.O. Box 68503
  189.                  Virginia Beach, Virginia  23455
  190.  
  191.